2026年5月28日
By: Chase

agent skills学习与实践

前言 Preface

记录以帮助我理解为什么需要, 以及设置了之后的好处.

简单理解

正常对话的token消耗是线性增加的.

// 第一次:
用户: 你好.
AI收到: 你好啊.

// 接着:
用户: 你好.
AI收到: 你好啊.
用户: 今天天气如何.
AI收到: 你好 + 你好啊 + 今天天气如何.

当对话上下文到达一定程度, AI会压缩一次之前的对话, 从而减少每次的token消耗.

而我理解设置的rules和skills的意义, 就是

  1. 省token, 我是穷鬼.
  2. 减少重复提需求.

比如我可设置

  • rule: 忽略每次你好的打招呼
  • skill: 应用我礼貌的人设

token消耗应该就变成了

用户: 你好.
AI收到: 你好啊.
用户: 今天天气如何.
AI收到: "你好, 你好啊."(忽略但知道我很礼貌) + 今天天气如何.

Skills

中英文差别

一般开发过程中基本都是用中文沟通, 但是问了GPT, 他给出的建议是用英文.

以下词在agent prompt中约定俗成.

英文关键词模型理解
MUST强制
NEVER禁止
ALWAYS必须执行
ONLY限制范围
DO NOT禁止
REQUIRED必选
BEFORE前置步骤
AFTER后置步骤

Matt Pocock套餐

最近刷到Matt的工作流, 演讲很棒, 就是嘴有点碎. 这里学到了几个, 打算实践并加入自己的理解.

  • /grill-me
  • /to-prd
  • /to-issue
  • /tdd

工作流如下: 图-0

我在图里的每个大模块都标注了结尾处可以新开agent对话框, 或者清除聊天历史, 以节省token消耗并保持context在较小的状态.

详细的skill内容就不贴了, 他已经全部开源了, 地址在这.

grill-me

---
name: grill-me
description: Interview the user relentlessly about a plan or
design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

这个skill很简单, 达成共识.

虽然现在已经有了PlanMode, 但是直接通过PlanMode得到的需求说明书也并没有那么细, 而且很容易拿到一篇大文, 我反正是很少全文细读.

拆成单问题的QA模式, 反而会让你每一步专注思考需求.

我目前主要使用还是Cursor, 我加了句 Use select UX to decide the answer., 更方便内置agent工具使用.

to-prd和to-issues

---
name: to-prd
description: Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
--

---
name: to-issues
description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
---

这两个可以放在一起写, 基本上就是把任务拆成标准格式 => 发到github => 作为开发前的指导需求文档.

对应到我们熟悉的敏捷开发里的工作里, to-prd得到的基本上就是feature/sprint级别的需求文档. to-issues得到的是下面的子任务.

比较值得提的点:

  1. 他用了AFK(away from keyboard)HITL(human-in-the-loop)标签来区分issue, 前者是AI立刻就可以开始写的, 后者是需要人为参与或者进一步提供指导信息的, 比如到supabase里设置点什么或者就某些问题进一步回答细节.
  2. 拆issue时, 他强调了纵向模式. 举个例子: 比如做一个登录注册模块. AI可能会拆成:
1. UI完成登录, 注册, 忘记密码页面
2. 登录, 注册, 忘记密码的接口和数据库
3. 联调, 测试.
4. ...

这是不好的横向模式, 因为你得到3完成才能测试和收到反馈. 好的拆分是

1. 前后端完成登录功能, 测试.
2. 前后端完成注册功能, 测试.
3. 前后端完成忘记密码, 测试.
4. 提组件优化.

TDD

---
name: tdd
description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
---

与其说tdd是个skill, 不说是一个设计理念, 都是围绕先写不通过的red测试 -> 代码 -> 所有red测试变green.

这个skill在之前大火的superpowers里也有.

我让GPT比较了一下两个版本的区别:

superpowers 版 test-driven-development 更像 TDD 铁律手册。重点是:

  • 必须先写测试
  • 必须亲眼看到测试失败
  • 测试没先失败就不算 TDD
  • 先写了生产代码就应该删掉重来
  • 强烈反对“测试后补”“这次先跳过”
  • 对 mock 反模式有更细的配套文档

Matt Pocock 版本的 /tdd 更像 真实项目里的 TDD 工作流。重点是:

  • 测试要验证公共接口和用户可观察行为
  • 不要测试实现细节、私有方法、内部协作者
  • 先和用户确认接口变化、重要行为、测试优先级
  • 一次只做一个 vertical slice:一个测试,一个实现
  • 反对一次性写完所有测试再写实现
  • refactor 时关注模块边界、deep modules、可测试性

一句话总结:

GitHub 版管的是:你有没有真的按 TDD 做。 /tdd 管的是:你写出来的测试是不是好测试,流程是不是适合真实项目。 我会建议以 /tdd 为主,吸收 GitHub 版的两条硬规则:必须先看到测试失败,以及 失败原因必须正确。

工作流实践

我用/grill-me -> /to-prd -> /to-issues -> /tdd干了一个跨境电商独立站的新项目, 全程都在用Cursor, 之前是composer2, 上周出现了composer2.5, 就切换了.

目前比较满意, issues全都在github上.

我基本上都是

  1. main切prd分支
  2. prd分支拆了之后切issues分支
  3. issues每一个提PR到prd分支, 看情况是自动合并还是我review再合并.
  4. prd上面的issues全部干完后, 我去终点关注test, 或者人工测功能. 然后继续在prd分支上酌情增加fix-issues.

从图里能看到, prd, issues各自都挂有分支, revert和进度管理都很方便.

图-1

模型的优劣

Composer对比GPT5.5Opus4.7可谓是非常便宜了. 95%的情况Composer都能解决, 解决不了或者卡壳有点久的, 我换了模型还是会卡壳, 或者说多轮烧token, 我是$20/month穷鬼套餐, 遇到这种情况我基本就手动停了, 选择人工介入.

偶尔我会调用GPT5.5, 去review架构层面的东西. 或者在设计方案的阶段, 多个模型询问讨论做决策.

人为参与的点

  1. 我会重点review, prd拆issues的合理性, 确保每个issues是个小闭环, 起码是做完能自测.
  2. 当AI告诉我当前prd上已经全部做完了, 我会重点看test. Function或者Component这种自动化很全的我基本不看, 我只看playwright的E2E覆盖. 这在古法编程时代, 就相当于每个功能阶段性的产品展示了.
  3. 细节打磨, 比如form提交的warning提示词这种小细节, 整体页面的美感, 这些还是需要人去试了试再让AI继续improve.

其他碎碎念

UI层面目前依旧有风格很AI的问题, 我感觉这个问题应该会慢慢解决, 但不会一步到位.

我最近尝试了base44, 出来的UI已经很不AI了, 这是基于我的一句话泳衣跨境独立站生产的首页截图.

图-0

但是目前这个网站是前后端全部生成, 且不交付后端代码, 后期调整只能用他的平台token调教. 调整起来很烧钱.

长期来看, 我认为美感, AI是学不会的. 我很难想象AI怎么判断0.3s Ease In-Out动画和0.2s Linear动画哪个感觉更好, 如果只是抄, 不同的组合和风格, 感觉就不一样了.

AI让很多人开始觉得自己无所不能, 但是日子并没有好起来.

Tags: Agent AI